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Title 

5 

Group hopping and channel zapping during transmission of multicast 
applications 

10 Technical field o£ the invention 

The present invention relates to a method, a system and a receiver 
for performing group hopping and channel zapping during 
transmission of multicast applications in a telecommunication 
15 network. 

Especially the present application is applicable in a wireless 
packet- switched telecommunication network. 

20 Background 

Universal Mobile Telecommunication System UMTS is being developed 
to offer wireless wideband multimedia service using Internet 
protocol. The UMTS as a third-generation 3G mobile communication 

25 system combines among others streaming with a range of unique 

services to provide high-quality Internet content to the mobile 
users. Images, voice, audio and video content are example of 
mobile multimedia services, which are delivered to the users via 
media streaming techniques. It means once the content has been put 

30 onto a media server, it can be delivered for example via streaming 
to the end users . 
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The streaming service in a wireless network is provided both to a 
single user by means of the so-called unicast connections and to a 
group of users by means of the so-called point-to-multipoint or 
even multipoint-to-multipoint communication. The point-to- 
5 multipoint services pose high demands on the network 

infrastructure and may consume considerable amounts of bandwidth. 
Some excunples of such services are video-conferencing, 
whiteboarding, real-time multi-user games, multimedia messaging, 
virtual worlds. This kind of point-to-multipoint applications use 

10 broadcast or multicast mode for transmission- Broadcast has the 
possibility of addressing a packet to all destinations like to 
every user on the network. Multicasting supports transmission to a 
group of the users in the network. Each user can register to a 
multicast group. When a packet is sent to a certain group, it is 

15 delivered to all users registered to that group. Multicasting is a 
service that permits sources to send a single copy of the same 
data to an address that causes the data to be delivered to 
multiple recipients. Under multicasting and broadcasting only one 
copy of a message passes over any link in a network and copies of 

20 the message are made only where paths diverge. In the following 

description the multicast is taken as an example. The application 
is applicable also to the broadcast applications. 

A server in the IP network provides the multicast service. The 
25 server stores the content, which is to be sent to the user by 
means of a multicast transmission. In the UMTS the Multimedia 
Broadcast /Multicast Service, MBMS, is provided. The task of the 
server is fulfilled by means of the Broadcast Multicast - Service 
Centre MB-SC, which is an MBMS data source. The MBMS data may be 
30 scheduled in the MB-SC, for example for transmission to the users 
every hour. It offers interfaces to a content provider, so that 
said content provider can request data delivery to the users . The 
BM-SC may authorise and charge content providers. Detailed 
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description of the BM-SC is given in 3GPP TR 23.846 "Multimedia 
Broadcast/Multicast Service; Architecture and Functional 
Description" . 

5 In the wireless networks the end users are characterized by a 

variety of mobile terminals with a wide range of capabilities like 
for example display size. In current multicast solutions the 
source of data, like the server adapts the transmission conditions 
to the slowest receiver. This method is not sufficient when 

10 clients are charged for the service and for the bearer that is 

used for the service. In addition different radio-access networks 
make multiple maximum- access link speeds available. Because of the 
physical characteristics of the cellular radio networks, the 
quality and, thus, the data rate of ongoing connection will vary 

15 contributing to the heterogeneity problem. 

Receiver-Driven Layered Multicast, S. McCanne, V. Jacobson and M. 
Vetterli, "Receiver-driven layered multicast". In Proc . of ACM 
SIGCOMM'96, pages 117--130, Stanford, CA, August 1996, is a well- 

20 known technology in the Internet and it solves some of the above- 
mentioned problems. Several improvements have been proposed. The 
basic idea is as soon as more capacity becomes available, the 
receiver changes a subscription level by joining to an additional 
multicast group and adapts the stream to the actual network 

25 conditions. The server provides a number of quality levels, and 

the member decides which quality level fits to his current network 
condition. In other words, if there is an unsatisfied client with 
the offered quality, a change to another group with the requested 
quality is performed. The user gets separately information only 

30 about the additional group. 
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Actually, receiver-driven sub-grouping can deal with changing 
network conditions, keeping the subjective quality at a reasonable 
level . 

5 The clients need total knowledge on available multicast groups in 
order to make correct decision on which group to join- Moreover, 
offering different content in various groups need to be announced 
in the usual way using for example a Session Application Protocol 
SAP. In case of streaming applications, several coded variants of 

10 the same video clip are stored on a content server and send out to 
different multicast groups. Clients can then choose the variant 
that they prefer or that their terminals are able to receive and 
to process. The disadvantage is that with the usual way of 
announcement separated information about a multicast group is 

15 distributed. There are no possibilities to distribute information 
about dependences between the simple multicast groups. The users 
do not have any possibilities to change to another kind of content 
without performing an end-to-end protocol interaction. Therefore 
the problem is basically that there is no dynamic or flexible 

20 mechanism within the network to let clients zap fast between 

channels with different content- Further problem of the current 
solutions is that the user cannot easy hop between different 
groups with different quality levels. 

25 Summary and description o£ the invention 

It is an object of the present invention to provide a dyneunic 
solution for performing hopping between multicast groups and 
zapping between channels within a telecommunication network. 
30 The invention is embodied in a method as disclosed in claims 1, 15 
and 17. Advantageous embodiments are described in the dependent 
claims . 
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The method of claim 1 discloses a solution for performing a 
flexible multicast of multicast data to a multicast group within a 
telecommunication system. The multicast data is provided by a 
broadcast/multicast server and transferred to the users registered 
5 to the multicast group by means of channels. The flexible 
multicast is performed in the following way. Multi-channel 
multicast groups (B1,B2,...) are provided, wherein each multi- 
channel multicast group is configured and uniquely identified by 
means of a first identifier. Each multi-channel multicast group 

10 offers at least one channel wherein the channel transports content 
and is uniquely identified by means of a second identifier. An 
announcement multicast group (A) is provided for informing about 
availability and configuration of at least one of the multi- 
channel multicast groups (B1,B2,...) wherein the user establishes a 

15 connection through the telecommunication network and the 

announcement multicast group (A) is announced to the user. The 
user joins the announcement multicast group (A) and the first 
identifier is used to between multi channel multicast groups 
(Bl,B2,...) and the second identifier is used for zapping between 

20 the channels. 

The present invention makes it possible to zap between channels 
within one multi-channel group and to hop between different multi- 
channel groups. The proposed solution is either client driven, it 
25 means the user decides to change the multicast group or it is 

server driven, it means the operator forces the user to move group 
members from one multicast group to another group. 

The advantage of the invention is a guarantee of a better service. 
30 Instead of delaying the whole group, since multicast can only work 
if the slowest user equipment is considered, the slow user 
equipment can be treated specially. 
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In the following some excunples are given for possible motivations 
for hopping between groups. 

Hopping between multicast groups can be performed in case the 
5 clients are unsatisfied with the offered quality. Because the user 
is informed by means of the announcement multicast group (A) about 
the content quality served by the other multi-channel multicast 
group, the user can decide to change the multi-channel multicast 
group in order to receive the requested content quality. 

10 

Another example for the motivation for hopping is in case the 
transmission quality in multi-channel multicast group Bl differs 
from that in multi-channel multicast group B2 , because for example 
the transmission is mapped on a different radio bearer or in an 

15 other radio access system. A source may stream the same content 
with different codecs on different groups and clients are moved 
between these groups. The reason for hopping can be also the 
different cost for using the multi-channel multicast group Bl or 
B2, for example the clients may choose the cheaper, and service 

20 providers may choose the more expensive service. 

In case of the server driven method the group hopping is used for 
load balancing, on this way the service provider wants to control 
the mapping of users to multi-channel groups. 

25 

In a preferred embodiment the hopping between the multi channel 
multicast groups is performed by means of jo in -and- leave 
transactions to and from a multi channel multicast group. This is 
realised for example by means of the well known Internet Group 
30 Message Protocol IGMP protocol. 



In an advantageous embodiment of the present invention the 
configuration of the multi channel multicast group is performed by 
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means of parameters defining different transmission quality, 
coding method, prise, protection key, reliability, expected jitter 
or restricted to certain subscriptions. 

5 Further the location dependent information are considered, so that 
the present invention is advantageous for an intelligent traffic 
information provisioning, in which the multicast groups are 
defined per region with its specific parameters like the traffic 
information, weather or travel direction of the users in order to 

10 provide an intelligent traffic guidance. The present invention is 
used to generate hierarchies in the group management, which leads 
to better sub-grouping. For instance, the user expresses general 
interest in particular information, like weather, travel, sport 
and the network cares about location dependent subgroup 

15 management. In order to provide full functionality including 
support of different service quality levels, with different 
tariffs for example business and student tariff, a clever 
combination of client driven and server driven sub grouping is 
proposed. 

20 

In one embodiment of the present invention the joining to the 
multi channel multicast group is user-driven. It means the user 
takes the decision to hop between the multi channel multicast 
groups taking into consideration relevant parameters, like for 
25 example the subscription, the expected transmission quality 

depending on the user terminal or the costs of the transmission. 

In other embodiment of the present invention the joining to the 
multi channel multicast group is server driven with a mechanism 
30 for forcing the users to hop between the multi channel multicast 
groups. With this solution the operator can control the network 
resources . 
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In a preferred embodiment of the invention the first identifier is 
a multicast address of a multi channel multicast group. This 
address is used to join or leave a multi channel multicast group. 
The second identifier depends on the used access network. For 
5 example the identification of the access bearer can be used. 

Another example is an identifier identifying the multicast data 
flow transported on one access bearer. In this case each channel 
is mapped on the same time slots, when time-multiplexing is used. 
Of course also a combination of both is possible and advantageous. 

10 For example in case four channels are included in a multi-channel 
group, then a base station may multiplex first two channels on one 
access bearer and the second two channel on a second access 
bearer. Within an access bearer the channels are identified by 
means of the identifier identifying the multicast data flow 

15 transported on one access bearer. A terminal has to switch either 
between access bearers or between time- slots within one access 
bearer in order to zap between channels . 

In a preferred embodiment of the invention the announcement 
20 multicast group A is sent regularly, in certain intervals or 

continuously. It depends on the implementation considering the 
aspect how often the users are to be informed about the available 
multi channel multicast groups. 

25 The channels can be described by means of some further parameters . 
These parameters are sent by means of the announcement multicast 
group (A) or they can be included in each multi-channel multicast 
group. The second the receiver needs to scan multi-channel 
multicast group to retrieve the detailed information on a channel. 

30 

Further the present invention proposes a list of multi -channels 
groups not yet established but for which users have already shown 
interest. Said list is multicasted to the users by means of the 
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announcement multicast group A, so that the user can consider to 
use the proposed multicast group by informing the multicast 
server. The multicast server uses this information for taking a 
decision about an establishment of a new multicast group in case a 
5 reallocation of the resources is to be performed. A certain 

threshold level of users interest is taken into account by the 
decision. The new established multi channel multicast group is 
announced to the users to join them to the new multicast group. 
When the last user of the multi channel multicast group leaves, 
10 said group is dissolved. The described mechanism of establishment 
or release of a multicast group results in transient groups with 
dynamic membership, which guarantees a high dynamics and 
flexibility of the present invention. 

15 Further it is proposed to have a system adapted to perform the 
flexible and dynamic hopping between the multicast groups and 
zapping between the channels within one multicast group according 
to claim 15. The system has means for announcement of the 
announcement multicast group (A) to the users. This feature can be 

20 implemented in a multicast /broadcast server. Further the system 

has means for joining the user to the announcement multicast group 
and also means for joining the user to the multi channel multicast 
group using the first identifier. Said means are also used when a 
user is to be forced to change a multicast group. Means for 

25 zapping the user between the channels using the second identifier 
are provided for zapping between channels. 

Further according to claim 17 it is proposed to have a receiver 
like for example a mobile terminal adapted to perform the 
30 multicast flexible and dynamic hopping between the multicast 
groups and zapping between the channels within one multicast 
group. The receiver has means for receiving the announcement 
multicast group (A) . Further the receiver has means for joining 
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the user to the announcement multicast group for example an IGMP 
message. Means for joining the user to the multi channel multicast 
group using the first identifier and means for zapping between the 
channels using the second are provided for changing the multi- 
5 channel multicast group or a channel within said group. 

In an advantageous embodiment of the present invention the 
receiver has means for tuning the receiving data wherein the 
second identifier is used to select the appropriate bearer on 
10 which the channel is being transmitted in order to switch between 
access bearers. 

Further the receiver has means for de-multiplexing the channels 
according to the second identifier, which identifies the multicast 
15 data flow transported on one access bearer. 

In the following a detailed description of the invention is given. 

Fig.l: Presentation of multi-channel multicast group with 
20 different channel quality and of the announcement multicast group, 
Fig. 2: An embodiment of the present invention with time sequence 
of the exchanged messages. 

Packet-switched domain in a UMTS network and in addition the radio 
networks and the IP multimedia subsystem, 

25 

As proposed in the present invention an announcement multicast 
group is to be introduced for informing the users about the 
availability and the configuration of the available multi-channel 
multicast groups. The announcement multicast group A can convey 
30 different information. However in order to recognise the different 
multi channel multicast groups a list of the available multi 
channel multicast groups described with Bl, B2 , ... are to be 
provided. Each multi channel multicast group is to be identified 
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by means of a multicast address, which is required in case a user 
decides to join a multi channel multicast group for receiving the 
multicast data sent on this group. The multi channel multicast 
group is specified by means of different configuration parameters, 
5 like for example audio-visual quality level, coding, price, 

protection, reliability, expected jitter or restricted to certain 
subscriptions . 

In the following an example of the content of the announcement 
10 multicast group A is given. 

Bl: MCAddrl, 768 kbps, MPEG4, 2€, protection key 1, ... 
B2: MCAddr2, 384 kbps, MPEG4, 1€, protection key 2, ... 
B3: MCAddrB, 64 kbps, QuickTime, free, free access/no protection, 

15 

It means the announcement multicast group A announces three multi 
channel multicast groups Bl, B2, B3 identified by means of a 
corresponding multicast address, MCAddrl, MCAddr2, MCAddr3 . 

20 Further each of the multi channel multicast group has different 
quality; Bl transfers data with 768kbps, B2 with 384 kbps and B3 
only with 64 kbps. Two coding methods are applied, MPEG4 and 
QuickTime. The cost for usage of the multi channel differs between 
2 and no costs. Also the protection of the data is performed in 

25 different ways depending on the protection key. 

However these are merely examples. The various multi-channel 
groups can also differ only in a subset of said parameters. For 
example different but overlapping set of channels, with the Scune 
30 audio-visual quality level and coding but with different 

protection allow access to a certain multi-channel group only to 
the owners having a specific protection key. In this example. 
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hopping between multi -channel groups is only possible between 
those for which a particular user has the protection key. 

The multicasting of the announcement multicast group A is repeated 

5 regularly, in certain intervals or continuously- It depends on the 
implementation and on the fact how often the users should be 
informed about the available mul ti -channel s . The propagation of 
the announcement multicast group A can be realised by means of the 
Session Announcement Protocol SAP ,Mark Handley. SAP: Session 

10 Announcement Protocol. Request for Comments 2974, Internet 

Engineering Task Force, October 2000) . The user receives the 
announcement multicast group message after attaching to the 
network. The message includes the multicast address of the 
announcement multicast group so that the user can register to the 

15 announcement multicast group in order to receive regularly 

information concerning said group. The joining of the user to the 
announcement multicast group can be also realised by means of an 
automatic subscription via the user subscription. It means the 
user is automatic subscribed to the announcement multicast group 

20 (A) after attach to network using information stored in his 

subscription being administrated in a central data base, like for 
example the Home Location Register HLR. Said information is used 
to perform a join operation for each pre- subscribed multicast 
group after a user is attached to the network. Since the user 

25 receives frequently information about the available multicast 

groups by means of the announcement multicast group the user can 
join and leave a multicast group during an established connection. 

Additionally the network operator can provide further information 
30 for moving users from one multi channel multicast group to other. 
The information can be for example that all users, who have a 
Subscription Bronze, which describes the level of the accessible 
service, should move from the multi channel multicast group Bl to 
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the multi channel multicast group B3 . The reason for the moving 
can be that the multi channel multicast group Bl offers a higher 
transmission bandwidth, which is foreseen for the users with a 
Gold Subscription. This kind of information is transmitted on the 
5 announcement multicast group A, so that the user can take this 
information into consideration by choosing a multicast group. 

There are different motivations for moving between the multi 
channels groups. However the motivation can be manifold. It can be 

10 the visual or aural quality of the content (higher or lower 

resolution), different bitrate, delay, jitter, reliability and 
protection and of course all possible combinations of these. The 
decision can be met by the user, who for exeutiple move to a multi 
channel multicast group offering the requested service on lower 

15 cost- 

Further the motivation to hop the users between the multi channel 
multicast groups can come from the operator/ server in order to 
administrate the radio resources. The network operator can force 

20 clients with terminals with low resolution to move to a multi 

channel multicast group, which is sending the requested content 
with the low resolution, like for example to the multi channel 
multicast group 33 serving clients interested in 320x240 
resolution in order to save the radio resources for terminals with 

25 higher resolution. 

In case the operator wants to control the allocation of the users 
in the multi channels groups then a mechanism for forcing the user 
to hop are to be provided. For example the information on who has 
30 to be in which multi -channel multicast group is conveyed to the 
key server, such that a client who has to move, for example from 
81 to 33, gets only the decryption keys necessary for the multi 
channel multicast group 33 and not longer those for 31. 
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Hopping between multi-channel multicast groups is realized by 
means of a mechanism using the so-called join-and- leave 
transactions for joining and leaving a multicast group on which a 

5 particular multi-channel group is being transmitted. Usually a 

terminal should first join a new multicast group and then leave an 
old multicast group to ensure a smooth transition. However, it 
depends on the terminal capabilities whether a terminal can 
receive two or more multi-channel multicast groups in parallel or 

10 not. If a terminal cannot receive more than one multi-channel 

group, then it has to leave the old multi-channel multicast group 
before it joins the new one. 

The join-and- leave transactions can be realised by means of a 
15 protocol called the Internet Group Message Protocol IGMP. Thus 

this protocol lets the system know which users currently belong to 
which multicast group. This information is required by the 
multicast routers to know which multicast data packet is to be 
forwarded onto which interface. 

20 

The IGMP is a part of the IP layer and the IGMP messages are 
transmitted in IP data packets. The version 1 of IGMP is described 
in RFC 1112 ''Host extensions for IP multicasting" S.E. Deering, 
Aug-01-1989. RFC 2236 "Internet Group Management Protocol, Version 

25 2" W. Fenner, November 1997 describes the version 2. The IGMP has 
been developed for IP version 4 . In Internet Protocol IP version 6 
there is a similar protocol called Multicast Listener Discovery 
MLD, which is used for the Scune purpose as the IGMP. The 
description of the first version of MLD can be found in RFC 2710 

30 "Multicast Listener Discovery (MLD) for IPvS" S. Deering, W. 

Fenner, B. Haberman, October 1999. However the messages used in 
MLD correspond to the IGMP messages. In the following the IGMP 
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will be used as an example. Although this should not be restricted 
to the IGMP. 

In principle the IGMP uses two basic messages to fulfil its tasks, 
the mexnberslxip report and the membersliip g[uery message. A 
multicast router sends a membership query at regular intervals to 
see if any user still belongs to any group. A user responds to an 
IGMP query by sending a IGMP report for each group that still 
contains at least one user. A user joins a group by sending the 
membership report message. In order to save the transmission 
resources it is more efficient that the mechanism is controlled by 
the user. It means the user sends a IGMP membership report in case 
the user wants to register to a multicast group. The de- 
registration can be performed by means of an explicit leave 
message, IGMP Leave. However these messages are not standardised 
jet . 

The result of the join-and- leave transactions is a table with its 
interfaces having at least one client in a multicast group. The 
20 router forwards the received multicast data out the interface, 
which has at least one member. 

In the following a preferred embodiment of the establishment of a 
new multi channel multicast group is described in more details. 

25 

In case a BM-SC server receives a notification from the user that 
the offered multicast channel does not fulfil the requirements, 
for example transmission on the channel is too slow or too fast 
for the user's device, then instead of adapting, in this case by 
30 increasing or throttling, the quality of the channels for all 

members of the multi-channel group according to the requirements 
of just a few clients, said server decides to open a new multi 
channel multicast group with a matching quality. 



10 
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Optionally, list of multi-channels groups not yet established but 
for which clients have already shown interest can be used in order 
to chose the matching multi channel multicast group. For this 
5 purpose the operator sends a list with the descriptions of multi- 
channel groups that could be opened by means of the announcement 
multicast group A. 

The BM-SC server operator takes the decision about the 
10 establishment of the new multi cheuinel multicast group. In one 
embodiment the new group is opened only if a certain threshold 
level is reached, for example if the number of users, which 
request different quality, is high enough. This requires that for 
each multi -channel group the BM-SC server keeps track of client 
15 notification at least until they are worked off or until they are 
expired. Vice versa, when the last member of the multi channel 
multicast group leaves, said group is dissolved. This method 
results in transient groups with dynamic membership. 

20 By means of the announcement multicast group A the user gets the 
information about the available multicast groups with the 
corresponding multicast addresses. Said multicast addresses are 
used as parcuneters in the IGMP membership and IGMP leave message 
to inform the BM-SC about the multi channel multicast group to 

25 which the user wants to register or de-register. 

The establishment of new multi-channel groups on client 
notification requires that the BM-SC server counts requests for a 
certain multi -channel group and keeps track on those group members 
30 that are interested. The clients need to tell the BM-SC server 
their interest identifying details on the multi-channel group. 
This can be released by means of a so-called multi-channel group 
interest message containing the details. Said message can be 
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implemented for example as a new message or as an enhancement of 
the IGMP or MliP or even as a HTTP message. As soon as the counter 
is above a certain threshold value, set by the operator via a 
management interface, the BM-SC server establishes a new multi- 
5 channel multicast group and informs about its availability on the 
announcement group A. Optionally the BM-SC informs about the new 
established multi channel multicast group all clients who have 
expressed their interest by means of a so-called multi-channel 
group now available message, which is implemented accordingly to 
10 the multi-channel group interest message. The interested users 
join the new group for example by means of the IGMP membership 
report message. 

The above mentioned principle of the multi channels groupi with 
15 different channels quality is described in the following according 
to figure 1« 

The figure 1 shows three multi channel multicast groups Bl, B2 and 
B3 and the announcement multicast group A. Each of the multi 

20 channel multicast group transmits a number of channels, the multi 
channel multicast group Bl and B2 transmits four and the multi 
channel multicast group B3 three channels. Each of the multi 
channel multicast groups, Bl, B2, B3 offers different quality. In 
figure 1 the quality is depicted by means of the lines with 

25 different width, for exan^le the multi channel multicast group Bl 
offers higher Quality of Service QoS level then the multi channel 
multicast group B3 . The content on each multi channel multicast 
group is the Scune, the difference is the offered QoS. The user or 
the operator, depending on the motivation, takes the decision to 

30 change between the multi channel multicast groups. As already 
described the announcement multicast group A carries the 
information about the multicast groups, about the channels and 
eventual some others parameters required to perform for exeunple 
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the zapping between the channels within a multi channel multicast 
group . 

In the following the structure of the channels in a multi channel 
5 multicast group are described in more details. 

In a preferred embodiment of the invention a multi channel 
multicast group transmits a niimber of channels carrying multicast 
data, like content, which are to be multicasted. For example on 
10 each channel different television programs as a content can be 
provided. In the following example, the multi channel multicast 
group Bl has 10 different television programs. The other multi 
channel multicast group B2 has 20 channels and B3 3 channels. 

15 Bl: 10 channels: CNN, BBC, ... 
B2 : 20 channe 1 s : CNN , BBC , ... 
B3: 3 channels: ARTE, QVC, ... 

It might even be that on several channels the ssime content is 
20 being transmitted, but just time-shifted to allow jumping in 
sequential information, for excunple 

Bl: 10 channels: CNN, BBC, ... 

B2: 20 channels: CNN, BBC, BBC{+10 min) , BBC (+2 0min) 
25 B3: 3 channels: ARTE, QVC, ... 

The protection of each of the channels may vary. Either the 
protection key is stated for each channel, for example CNN has 
none protection, BBC can be protected with the protection key 1, 
30 or the user has some protection keys stored on its device and 

simply tries to get access to the content of a particular channel. 
This works in a similar way like with the pay TV in Germany today. 
The content is decoded, when a protection key is available. 
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otherwise only noise is seen. 

In other embodiment of the present invention the detail 
information on the channels is included in each multi-channel 
5 group. However in this case a terminal needs first to scan a 

multi-channel group and retrieve the detail information of said 
multi -channel group before a certain channel of said multi-channel 
group can be accessed. 

10 In the following the zapping between the channels within a multi 
channel multicast group is described. 

As already mentioned each multi-channel multicast group B includes 
at least one channel. If more than one channel is present, general 

15 information on the channels is available via the announcement 

group A, For each channel in the multi-channel group, appropriate 
further information on how to receive the channel must be 
transmitted. Said further information needed to zap between the 
channels is preferably transmitted on each multi-channel multicast 

20 group. Of course this information can also be included for each 
multi-channel group B in the announcement group A. The further 
information describing the channels depends on the used access 
system. For example each channel of a multi-channel group can be 
mapped on different access bearer. Each access bearer is uniquely 

25 identified by means of the second identifier. For example in the 
mobile networks the bearer identifier can be used as the second 
identifier and in the SONET networks the frame class. In order to 
zap between channels a terminal tunes the receiving data and uses 
the second identifier to select the appropriate bearer on which 

30 the channel is being transmitted in order to switch between access 
bearers . 
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Alternatively, the second identifier identifies the multicast data 
flow transported on one access bearer. Said identifier is provided 
besides the multicast address of the multi-channel group. In this 
case the data is transmitted on the same access bearer and the 

5 receiver has to de-multiplex the channels by means of the second 
identifier. For example if four channels are included in a multi- 
channel group, then all four are multiplexed into one byte stream 
on a single access bearer. Each of the four channels has a unique 
second identifier. The transmission is usually realized by means 

10 of time multiplexing, but other multiplex schemes are feasible as 
well. In the example of a time-multiplexing with fix time-slots, 
each channel is always mapped on the same time-slot and 
subsequently de-multiplexed. In this example the second identifier 
for each channel is the time slot number on which the channel is 

15 mapped. A terminal has to switch between time-slots in order to 

zap between channels. The switching is the task of a transceiver, 
for example a first channel is mapped on time slot 2 and a second 
channel is mapped on time slot 4, and the terminal is currently 
tuned only to the first channel it means the time slot 2 is 

20 accessed, in case the channel has to be changed from the first 
channel to the second channel, the transceiver of the mobile 
terminal is to be informed to deliver the content from time slot 4 
instead of time slot 2. 

25 Other possibility is the combination of the above two methods. In 
this method the MBS server introduces the second identifier 
identifying the multicast data flow transported on one access 
bearer. Said second identifier is used by the Radio Network 
Controller RNC or by the base station to map the channels onto 

30 different access bearers. In this case the RNC/base station 

informs the BM-SC about the bearers and the BM-SC includes this 
information into the announcement multicast group (A) . For example 
in case four channels, 1-4, are included in a multi-channel group 
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B, then the base station/RNC may multiplex channel 1 and 2 on one 
access bearer and channel 3 and 4 may be multiplexed on a second 
access bearer. A terminal has to switch either between access 
bearers or between time-slots within one access bearer in order to 
5 zap between channels. 

In the following the method steps of an embodiment of the present 
invention is described in respect to figure 2 . 

10 The figure 2 shows the time sequence of the sent messages between 
the BM-SC server and the user. Mobile Terminal MT. An arrow 
indicates the direction of the sent message. Above a line the name 
of a message with parameters is depicted. 

15 In the first step the BM-SC announced the availability of the 

announcement group A by means of a session announcement mechanism, 
like for example the Session Announcement Protocol SAP, SAP: 
announcement multicast group A (MCAddr A) . In this embodiment said 
message carries as parameters the multicast address of the 

20 announcement multicast group A, MCAddr A, so that the user can use 
said multicast address to register to the announcement multicast 
group in order to receive the information trcuismitted on said 
group. For this purpose in the second step the user MT joins the 
multicast group on which the announcement group is being 

25 transmitted, IGHP: Menbersliip Request (MCAddr A) • In the third 

step the user retrieves the information on available multi-channel 
multicast groups via the announcement group, SAP: announcement 
multicast group A (MCAddr A; MCAddr Bl,B2; ) with some further 
parameters, which are the multicast addresses of the multi channel 

30 multicast groups, MCAddr Bl,B2; . These addresses are used by 
the user to register to a matching multi channel multicast group 
for receiving the content, the user is requesting for. The SAP: 
announcement multicast group A message is shown only once, however 
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as described above this message can be sent periodically, it 
depends on the operator's implementation. The user MT joins the 
multicast group on which multi-channel group Bl is transmitted, 
I6MP; Membership Request (MCAddr Bl) . In the example of the multi 

5 channel multicast group all channels are mapped on different 

bearers. The content of the multicast group is sent by means of 
the GPRS Tunnelling Protocol GTP with the identification 
parameters of the in the multi channel multicast group included 
channels- In this example the channels, channels 1-4 are 

10 identified by means of the access bearer. Bid 1-4, which are sent 
as the parameters of the message, GTP; multi channel multicast 
group BKBId 1-4, channels 1-4). The user MT can zap between 
channels by selecting different bearers using the identification 
of the access bearer. In dependence of the terminal capabilities, 

15 also multiple channels can be retrieved in parallel, for example 
for performing the picture in picture mode. 

In case the user MT switches from radio access UMTS to radio 
access WLAN, in which a higher bandwidth can be received, then it 

20 expects a better QoS. He knows, that the multi channels multicast 
group B2 offers the required QoS. Therefore the user MT leaves the 
multicast group that carries the multi-channel group Bl and joins 
the multicast group that carries the multi-channel group B2 . For 
this purpose the user sends the IGMP: Iioave (MCAddr Bl) and after 

25 that IGMP: Membership Request (MCAddr B2) . He knows that in the 
multi-channel group B2 the channels are time -multiplexed on one 
bearer. Therefore the channel identification. Chid is used to de- 
multiplex the channels sent on one bearer, GTPs multi channel 
multicast: group B2(ChId 1-4, channels 1-4). The terminal can zap 

30 between channels by selecting different time-slots being 
identified by means of the channel identifier Chid. 
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The description of the invention disclosure is based on the 
networks GPRS or XJMTS- However, it should be understood that the 
Scune mechanisms could be applied for any telecommunication network 
wanting to provide a flexible and dynamic multicast with a 
5 possibility of channel zapping. The solutions described in this 
invention merely cover some examples of possible information 
exchange. It should be understood that other messages may be used 
as carrier for the same or different information. 

10 
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